Universal performance monitor for power generators

ABSTRACT

The invention broadly encompasses a system including a communications network, a plurality of remotely located data sources to provide power data, the power data including quantitative and qualitative data of one or more power generation units, and a performance monitor in communication with the plurality of remotely located data sources through the communications network, the performance monitor including a communications unit to extract the power data from the plurality of remotely located data sources, a data conversion unit to transform the power data into a common data format, a data store to store the transformed power data, and a user interface unit to display the transformed power data on one or more client devices through the communications network.

This application is a continuation application of copending U.S.application Ser. No. 14/605,629, filed on Jan. 26, 2015, which is acontinuation of U.S. application Ser. No. 12/399,689, filed on Mar. 6,2009, which claims the benefit of U.S. provisional patent applicationNo. 61/034,912, which was filed on Mar. 7, 2008, all of which are herebyincorporated by reference in their entirety.

I. FIELD OF THE INVENTION

The invention encompasses a performance monitor for power generators,and more particularly to a performance monitor for power generators thatis adaptable to handle data from any data source.

II. BACKGROUND OF THE INVENTION

The power industry has been rapidly changing with the advent ofderegulation as well as other socio-economic factors. As a result,increases in efficiency and control of power generation costs arebecoming of more importance. To meet the industry needs, a large numberof siloed information technology (IT) applications have been introduced.However, these applications are typically not built with integration inmind with each application being too proprietary in nature andspecifically tailored for a particular power generation operation.Accordingly, collection and integration of data from these applicationsand systems are extremely difficult outside of the intended operation.Many utilities have sought to create a large scale data warehouse tosolve this integration problem with very little success.

Another difficulty with prior art systems is the disparate number oflocations even within the organization that needs access to the data.For example, within a power company, traders on a central trade floor,plant personnel at each power plant, engineers stationed regionally,management dispersed throughout the organization, and third parties allneed access to the data in some form. The traditional siloedapplications are typically client-server based applications and it isdifficult to provide access to everyone in need of the data.

In addition, due to the generally isolated nature of the prior artsystems as described above, combining qualitative event type data (e.g.,real-time or recorded plant operations data) and quantitative data(e.g., Supervisory Control and Data Acquisition (SCADA) and market data)becomes difficult and cumbersome, if not impossible, due to the size anddisparity of the data. On the other hand, such information is importantin determining proper operation of power generation as back officesettlement activities determine penalties associated with under or overproduction of power, for example. Typically, back office personnelmanually extract data from a number of different IT systems in theorganization to determine the activities that occurred in priorreporting periods. Many times, logs maintained in word processing orhand written documents must be searched manually.

Moreover, when a type of report is required, IT developers have todevelop some level of custom code to extract data from the data andformat the data properly onto a report. This task becomes even morecomplicated when disparate data sources with varying data formats areused.

III. SUMMARY OF THE INVENTION

Accordingly, the invention encompasses a system and method formonitoring power generation operations that substantially overcomes thelimitations and disadvantages of the related art.

In one embodiment, the invention encompasses a system and method forcollecting power generation operation data from disparate data sourcesand generating a report of the performance of the operation.

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be apparent from thedescription, or may be learned by practice of the invention. Theobjectives and other advantages of the invention will be realized andattained by the structure particularly pointed out in the writtendescription and claims hereof as well as the appended drawings.

To achieve these and other advantages and in accordance with the purposeof the invention, as embodied and broadly described, a systemencompasses a communications network, a plurality of remotely locateddata sources to provide power data, the power data includingquantitative and qualitative data of one or more power generation units,and a performance monitor in communication with the plurality ofremotely located data sources through the communications network, theperformance monitor including a communications unit to extract the powerdata from the plurality of remotely located data sources, a dataconversion unit to transform the power data into a common data format, adata store to store the transformed power data, and a user interfaceunit to display the transformed power data on one or more client devicesthrough the communications network.

In one embodiment, the invention encompasses methods of communicatingwith a plurality of remotely located data sources from a performancemonitor via a communications network, the plurality of remotely locateddata sources providing power data including quantitative and qualitativedata of one or more power generation units, extracting the power datafrom the plurality of remotely located data sources, transforming theextracted power data into a common data format, storing the transformedpower data in a data store, and displaying the transformed power data onone or more client devices through the communications network.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory and areintended to provide further explanation of the invention as claimed.

IV. BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention and are incorporated in and constitute apart of this specification, illustrate embodiments of the invention andtogether with the description serve to explain the principles of theinvention. In the drawings:

FIG. 1 describes a block diagram illustrating an overall systemarchitecture of an exemplary embodiment of the present invention;

FIG. 2 shows a block diagram illustrating an exemplary embodiment of acommunication interface architecture of the present invention;

FIG. 3 is an example of a config file in accordance with the presentinvention;

FIG. 4 shows a block diagram illustrating an exemplary embodiment ofgenerating a report interface in accordance with the present invention;

FIGS. 5A-5K show exemplary embodiments of a dashboard report interfacein accordance with the present invention;

FIGS. 6A and 6B show exemplary embodiments of a daily report interfacein accordance with the present invention;

FIGS. 7A and 7B show exemplary embodiments of a unit performance reportinterface in accordance with the present invention;

FIG. 8 illustrates an exemplary unit interface in accordance with thepresent invention;

FIG. 9 illustrates an exemplary unit attribute interface in accordancewith the present invention;

FIG. 10 illustrates an exemplary event log interface in accordance withthe present invention; and

FIGS. 11A and 11B illustrate an exemplary real time monitor inaccordance with the present invention.

V. DETAILED DESCRIPTION OF THE INVENTION General Description

The invention generally encompasses systems including:

a communications network;

a plurality of remotely located data sources to provide power data, thepower data including quantitative and qualitative data of one or morepower generation units; and

a performance monitor in communication with the plurality of remotelylocated data sources through the communications network, the performancemonitor including

a communications unit to extract the power data from the plurality ofremotely located data sources,

a data conversion unit to transform the power data into a common dataformat,

a data store to store the transformed power data, and

a user interface unit to display the transformed power data on one ormore client devices through the communications network.

In certain illustrative embodiments, the quantitative data includessupervisory control and data acquisition (SCADA) data and/or marketdata.

In certain illustrative embodiments, the quantitative data includesoperational cost data of the one or more power generation units.

In certain illustrative embodiments, the qualitative data includes eventlog data of the one or more power generation units.

In certain illustrative embodiments, the communications unit includes agateway application programming interface (API) unit to pull the powerdata from the plurality of remotely located data sources.

In certain illustrative embodiments, the conversion unit includes aninterface API unit to communicate with the gateway API unit and totransform the power data into the common data format.

In certain illustrative embodiments, the user interface unit includes analarm unit to issue and track alarms based on user-defined events.

In certain illustrative embodiments, the user interface unit includes areporting unit to display interactive reports on the one or more clientdevices.

In certain illustrative embodiments, the reporting unit includes any oneof a dashboard reporting interface, daily operational reportinginterface, unit performance interface, ad-hoc SCADA query interface, andunit status communications interface.

In certain illustrative embodiments, the user interface unit includes alibrary of extensible markup language (XML) configuration files, eachXML, configuration file being associated with a corresponding one of theinteractive reports to map the power data stored in the data storedirectly to the corresponding interactive report for display on the oneor more client devices.

In other embodiments the invention encompasses computer-implementedmethods including

communicating with a plurality of remotely located data sources from aperformance monitor via a communications network, the plurality ofremotely located data sources providing power data includingquantitative and qualitative data of one or more power generation units;

extracting the power data from the plurality of remotely located datasources;

transforming the extracted power data into a common data format;

storing the transformed power data in a data store; and

displaying the transformed power data on one or more client devicesthrough the communications network.

In certain illustrative embodiments, the quantitative data includessupervisory control and data acquisition (SCADA) data and/or marketdata.

In certain illustrative embodiments, the quantitative data includesoperational cost data of the one or more power generation units.

In certain illustrative embodiments, the qualitative data includes eventlog data of the one or more power generation units.

In certain illustrative embodiments, the step of extracting the powerdata from the remotely located data sources include pulling the powerdata from the plurality of remotely located data sources via a gatewayapplication programming interface (API) unit.

In certain embodiments, the step of transforming the power data includesconverting the power data into the common data format via an interfaceAPI unit.

In certain illustrative embodiments, the step of displaying includesissuing and tracking alarms based on user-defined events.

In certain illustrative embodiments, the step of displaying includesdisplaying interactive reports on the one or more client devices.

In certain illustrative embodiments, the interactive reports aredisplayed on any one of a dashboard reporting interface, dailyoperational reporting interface, unit performance interface, ad-hocSCADA query interface, and unit status communications interface.

In certain illustrative embodiments, the step of displaying includesconfiguring the interactive reports via a library of extensible markuplanguage (XML) configuration files, each XML configuration file beingassociated with a corresponding one of the interactive reports to mapthe power data stored in the data store directly to the correspondinginteractive report for display on the one or more client devices.

In another embodiment, the invention encompasses a computer-readablestorage medium, storing one or more programs configured for execution byone or more processors, the one or more programs comprising instructionsto:

communicate with a plurality of remotely located data sources from aperformance monitor via a communications network, the plurality ofremotely located data sources providing power data includingquantitative and qualitative data of one or more power generation units;

extract the power data from the plurality of remotely located datasources;

transform the extracted power data into a common data format;

store the transformed power data in a data store; and

display the transformed power data on one or more client devices throughthe communications network.

Reference will now be made in detail to the embodiments of the presentinvention, examples of which are illustrated in the accompanyingdrawings.

The system and method of the present invention is a flexible solutionboth in terms of the type and amount of data processed and in terms ofmonitoring and reporting to the above-identified problems of the priorart. In general, the system and method of the present invention is ahosting asset performance monitoring and reporting tool used by ownersor power generators, such as independently owned utilities,municipalities, and cooperatives, for example. It is to be understoodthat other users and benefits may be realized without departing from thescope of the invention. The system and method of the present inventionprovides, for example, dashboard reporting (e.g., for management-level),summary/drill-down reporting (e.g., back office processing), dailyoperational reporting (e.g., operations), query interface for plantsupervisory control and data acquisition (SCADA) information on ad-hocbasis, and near real-time status and logging capabilities. Accordingly,the system and method of the present invention provides, for example,logged information created by automated plant monitoring systems and/orplant personnel as events occur with relative SCADA and marketinformation. The details of the system and method of the presentinvention is described below.

FIG. 1 shows a block diagram illustrating an overall system architectureof an exemplary embodiment of the present invention. As shown in FIG. 1,the system of the present invention includes a hosting monitoring center10 in communication with a plurality of remotely located disparate datasources 20 over a communications network 30. The communications networkmay be any data communications network, such as point-to-pointconnections, local area networks (LAN), wide area networks (WAN),Internet, etc. and may be over a wired or wireless communication medium.The remotely located disparate data sources 20 provide qualitativeinformation (e.g., events type data) and quantitative information (e.g.,market data) related to a hosted power generating unit. For example, asshown in FIG. 1, the hosting monitoring center 10 may be incommunication with a hosted power plant 20 a and SCADA data center 20 b.SCADA data center 20 b may be any data source that archives time-seriesSCADA or telemetry data of a power generator, also sometimes referred toas SCADA historian, such as megawatts produced, fuel consumption, etc.Generally, SCADA data center 20 b collects SCADA information from aplurality of power generations located within a defined region. However,any SCADA data source may be used without departing from the scope ofthe present invention. The hosted power plant 20 a provides internaloperations data of the power plant, such as operational event logs, theamount of power being generated, operational cost information (includingunit design and budget data), etc. “Budget” data, as used herein,includes financial/cost expectations as well as operationalexpectations, such as expected hours of operation, expected number ofstarting the generators over a projected time frame, how much power isexpected to be generated, etc. It is to be understood that the dataprovided by the hosted power plant 20 a may overlap with the informationprovided by the SCADA data center 20 b and may be used independently of,or in conjunction with, each other. Other remote data sources mayinclude market and financial information data services (not shown) thatprovide historic and real-time market information to the monitoringcenter 10.

The hosting monitoring center 10 includes power data server 12, marketdata server 14, and web server 16. It is to be understood that theseservers may be implemented in a single machine or a plurality ofmachines without departing from the scope of the invention. The powerdata server 12 and market data server 14 are configured to obtain datafrom any number of the disparate data sources 20. The data sources 20may be databases from hosted or unhosted systems, such as independentsystem operators (ISOs), regional system operators (RSOs), and SCADAdata centers, for example. The data may also be obtained from internaldata sources of hosted and unhosted system, such as data from internaldatabases, spreadsheets, and other software packages. The power datamay, in some embodiments, include market-type data such as, for example,power pricing, fuel pricing, or the like. The power data server 12 andmarket data server 14 convert the collected data into a common formatand store the transformed data in data store 18. The data store 18 maybe a single or a plurality of data storage devices and may beimplemented as a direct data repository or a relational database. Otherdata store configurations may be used without departing from the scopeof the present invention. The web server 16 communicates with clientdevices 40 to provide monitoring functionality to the users. Clientdevices 40 may be workstations, notebooks, digital personal assistants,and other data-enabled devices. The web server 16 processes the requestsfrom the client devices 40 and provides the requested information viareports and alarms to be described further below.

In an exemplary embodiment of the present invention, the web server 16communicates with the client devices 40 via web-based applications. Inthe exemplary embodiment, the client devices 40 only need a web browserand do not require any specialized applications. The web server 16includes a proprietary XML-HTTP callback architecture to initiaterequests from a browser from the client device 40, for example, back tothe web server 16.

FIG. 2 shows a block diagram illustrating an exemplary embodiment of acommunication interface architecture of the present invention. As shownin FIG. 2, the system and method of the present invention extract datafrom any number of disparate data sources 20 using a combination of webservices and SQL server integration services. For example, the interfacearchitecture in accordance with the exemplary embodiment of the presentinvention includes hosted Gateway API web service located behind thehosted system's firewalls, Hosting Interface API web service locatedbehind the firewall of the web server 16 that communicates with thehosted Gateway API, and SQL server integration services that communicatewith the interface web service, located on the data servers 12 and 14.It is to be understood that locations of the services and additionalservices may be used without departing from the scope of the invention.

The Gateway API in accordance with the exemplary embodiment of thepresent invention extracts data from the hosted system's internalapplications. The Gateway API accesses known APIs of other commercialsoftware systems and databases as well as any custom code needed to pulldata from the hosted system's internal proprietary applications. In anexemplary embodiment, the Gateway API extracts data and returns the datato the web service client as either a ADO DataSet, XML document, bytearray, string, or other similar data types.

The Hosting Interface API in accordance with the exemplary embodiment ofthe present invention provides the ability to communicate with theGateway API and contains interface logic to transform data into a commondata format. The Hosting Interface API, for example, pulls hourly,snapshot, and market data into the data store 18. The Hosting InterfaceAPI also generates log events from SCADA information.

The SQL server integration services in accordance with the exemplaryembodiment of the present invention drive the communication interfaces.The SQL server integration services utilize mapping data to execute,monitor, and report on scheduled interfaces for each hosted system. Inaccordance with the exemplary embodiment of the present invention, theSQL server integration services include “retry” logic to ensure thatdata is not missed due to any sort of system failure.

Once the qualitative and quantitative information of the hosted powergenerating unit (e.g., power plant 20 a) is available, the web server 16of the hosting monitoring center 10 provides customized reports to theclient devices 40 through report interfaces implemented on the webserver 16. The report interfaces in accordance with an exemplaryembodiment of the present invention are built from a customizablelibrary of report interfaces. The report interfaces of the presentinvention are customized using extensible markup language (XML)-based“config files” that contain information about what data to extract andhow to format the data on a report interface. Accordingly, the XMLconfig files in accordance with the present invention combine data fromany number of disparate systems into a comprehensive report. The XMLconfig files of the present invention simply map data from the datastore 18 directly to a report interface without requiring any customizedcode.

An exemplary embodiment of the present invention includes page configfiles and reports config files. The page config file, as shown in FIG.3, includes XML that may direct the page to change any property of thepage itself, or any property of any control on the page. This allows theuser interface to be changed without writing any code and increasesmaintainability across multiple client devices 40. For example, when thepage initially loads, the browser automatically looks for a page configfile. If a page config file is found, the browser processes the XML forthe page contained in the page config file. Each page or controlproperty identified in the XML is then set based on the page config filesetting. To illustrate, a button on the page may be hidden by settingthe visible property of the button equal to hidden. Furthermore,properties have been created on certain pages such as a unit statusreport interface, to be explained below, that allow customization ofentire sections of the page through the use of custom user controls. Inaddition, a config file may define standard .NET framework user controlsthat make-up a page. A particular user control may be overridden for oneor more user or customer locations (e.g., power stations or generators)via the config file. In some embodiments, a class (e.g., basePage)invoked because of a load page event may process the config file, changepage properties, and override user controls. In the case scenario wherea user control is overridden, a new user control may be loaded and alocal variable may be set accordingly.

The reports config file defines the layout of a report interface usingXML included in the reports config file. The reports config fileincludes XML fragments for each object to be displayed on the reportinterface (e.g., graph, pie chart, data table, etc.) The XML fragmentincludes information specific to the object being shown (e.g., locationon report, height, width, colors, etc.) as well as mapping informationback to the data store 18 as to what data should be displayed. There maybe mappings to multiple stored procedures defined for a single reportobject. For example, a chart may pull hourly megawatt (MW) data from onestored procedure and hourly price information from another inconjunction with a reporting engine to be described below. In anexemplary embodiment, reports config files may be defined for a singlereport but have different configurations depending on what hosted system(e.g., power plant) the report is for. For example, each reports configfile may have a “default” configuration defined. For any hosted system(e.g., power plant) or unit (e.g., generators) referred to as“locations,” where the report is to have a different look and feeland/or different data source, a subsequent “override” XML fragment isdefined for the location. Any location that does not have the overridefragment reverts to the default layout.

FIG. 4 shows a block diagram illustrating an exemplary embodiment ofgenerating a report interface in accordance with the present invention.A reporting engine 410 processes the page config file 420 and reportsconfig file 430, executes the stored procedures identified 440, andcreates and formats the report objects on a report interface 450. Thereporting engine 410 returns an HTML div containing the formattedreport. The reporting engine 410 loads the reports config file 430 andidentifies all of the stored procedures to call using an XPATH query.Once the reporting engine 410 has gathered a list of stored procedures,the reporting engine 410 executes each one, via a data access layer. Byexecuting all stored procedures once and holding them in memory forreport processing, extraneous database calls are eliminated to optimizeperformance. Each result set returned is stored in memory for theremainder of the report processing. The reporting engine then iteratesthrough the report objects to build the actual report interface 450.Object classes are defined for each possible report object (e.g., chart,pie chart, gauge, thermometer, note, table, etc.). The object classesinclude logic to generate HTML and format data appropriately for eachtype of report object. For each report object, the reporting engine 410creates an instance of the class and initializes the object generatingbasic HTML required. The reporting engine 410 then iterates through eachmapped data item to be illustrated in the report object and passes thedata item to the class from the appropriate result set extracted fromthe database earlier. The class processes the data into HTML (or XML)for the report item and finally returns the completely formatted HTML,which is then inserted into the HTML div tags.

In an exemplary embodiment of the present invention, the reportinterface 450 is categorized as one of the following: dashboard reportinterface, daily operational report interface, quantitativesummary/drill-down report interface (also referred to as “unitperformance” interface), an ad-hoc SCADA query interface, and unitstatus communication interface.

FIGS. 5A-5K show exemplary embodiments of the dashboard reportinterface. The dashboards page allows users to select any configureddashboard for any power plant within the data store 18. FIGS. 5A-5K showexemplary embodiments of the following dashboards, respectively:Operations, Megawatts (MW), Availability, Budget, Cost/Revenue, MTDPortfolio Summary, YTD Portfolio Summary, Fuel Trading Summary, PowerTrading Summary, Spark Spread Summary, and Financial Option Summary. Itis understood that other dashboard interfaces may be included withoutdeparting from the scope of the present invention. In the exemplaryembodiment, each dashboard is run for a selected month. However, othertime ranges may be used without departing from the scope of theinvention. For example, the user may select a power plant (i.e.,location) and a month out of a year, and refresh the report. An XML-HTTPcallback is made from the browser on the client device 40 to the webserver 16. The web server 16 receives the XML-HTTP request and createsan instance of the reporting engine 410 described above. The reportingengine 410 builds the report interface 450 as described above, which maybe an HTML div with report objects in it. The div is returned to thebrowser on the client device 40 that initiated the XML-HTTP call. Theclient device 40 refreshes the page on the screen with the newly createdreport. As shown in FIGS. 5A-5K, the dashboard interface includes acombination of report objects, such as gauges, bar graphs, line graphs,pie charts, and tables to provide an overall performance view of theselected location by integrating the qualitative and quantitative dataobtained from the disparate data sources 20, converted into a commonformat, and stored in the data store 18. The report object may beanimated as the information is provided to show movement of the variousgauges, bar graphs, line graphs, pie charts, and other graphicalrepresentations.

FIGS. 6A and 6B show exemplary embodiments of the daily reportinterface. The daily reports page allows a user to select a configureddaily report. FIGS. 6A and 6B show the Daily Summary and TradingSummary, respectively. Other daily reports may include Day ForecastedAvailability and Daily Log. It is to be understood that other dailysummary reports may be included without departing from the scope of theinvention. For example, the user selects a power plant (i.e., location),a reporting day, and refreshes report. An XML-HTTP callback is made fromthe browser of the client device 40 to the web server 16. The web server16 receives the XML-HTTP Request and creates an instance of thereporting engine 410 described above. The reporting engine 410 buildsthe report as described above, which may be an HTML div with reportobjects in it. The div is returned to the browser on the client device40 that initiated the XML-HTTP call. The client device 40 refreshes thepage on the screen with the newly created report. The daily reportinterface provides a summary of daily operational and financialactivities of the selected location by integrating the qualitative andquantitative data obtained from the disparate data sources 20, convertedinto a common format, and stored in the data store 18.

FIGS. 7A and 7B show exemplary embodiments of the unit performancereport interface. The unit performance report interface includesquantitative reports for daily, weekly, and monthly time horizon, forexample. In addition, the unit performance report interface includesdrill down capability so that hourly detail report data may also beretrieved. In the exemplary embodiment, the unit performance reportinterface includes the following reports: Operating Summary,Availability Summary, Actual Plant Dispatch, Actual Plant Usage,Budgeted v. Actual Dispatch, Budgeted Plant Usage, OperationalDecisions, Trading Decisions, Outage Decisions, Gas Balance, and TradeSummary. It is understood that other summaries may be included withoutdeparting from the scope of the invention. In the exemplary embodiment,the unit performance report interface and the items displayed aremaintained in an XML fragment in the unit performance page's reportsconfig file 430. For example, a user selects a report, a time frame, anda time horizon to initiate the report. The browser of the client device40 initiates a callback to the web server 16, which in turn calls astored procedure 440. The stored procedure includes logic to summarizethe data to the selected level (daily, weekly, monthly). When the resultset is returned to the web server 16, the page is correctly formattedwith the data into a table with the correct number of columns (e.g.,based on daily, weekly, or monthly) and returns the table to the browseron the client device 40. As shown in FIG. 7B, the unit performance pagealso includes drill down capability to drill down into a finergranularity (e.g., hourly details). Database mapping tables are used tomap summary items on the main page to the hourly detail. When a userclicks on a cell on the main report, the browser on the client device 40initiates a callback. The callback request is received by the web server16, and a stored procedure 440 is executed to retrieve mapped detailfrom the data store 18. The mapped detail is returned to the clientdevice 40 as a table, for example.

FIGS. 8-11B show exemplary embodiments of ad-hoc SCADA query interfaceand unit status communication interface in accordance with the presentinvention. For example, FIG. 8 illustrates an exemplary unit interfacethat displays operational information of a selected unit. Theinformation may include current status 805, operational statistics 810,schedules 815, event logs for the unit 820, and market data 825. Theinformation may be displayed for a selected date. It is to be understoodthat other information regarding the selected unit may be includedwithout departing from the scope of the invention.

FIG. 9 illustrates an exemplary unit attribute interface that displays asummary of the operational attributes based on region 905, control area910, unit 915, and date range 920, for example. Other criteria, such astype 925, season 930, and attribute 935 may be selected for viewing.

FIG. 10 illustrates an exemplary event log interface for a selectedunit. The event log may be sorted based on event type 1005 and daterange 1010, for example. In an exemplary embodiment, the event types mayinclude, but not limited to: Actual Shutdown, Actual Start, Derate (maxcap change), General Note, Schedule Change, Schedule Test, ScheduleUpdate, Trip (max cap change), and Workorder Impacting Operations.

FIGS. 11A and 11B illustrate an exemplary (near) real time monitor for aselected unit. In an exemplary embodiment, the operational data of ahosted power plant is updated every three (3) minutes. However, theperiod for update may be changed without departing from the scope of thepresent invention. The monitor may be selected based on region, controlarea, unit, and technology. Technology criteria may include, but is notlimited to, BWR, CCGT Gas, CCGT Steam, Diesel, Fluidized Bed,Combustion, Fossil Steam, Gas Turbine, Geothermal, Hydro, Jet, PumpedStorage, PWR, and Wind Turbine. As shown in FIG. 11B, the real timemonitor includes a pull-out to provide graphical representation of themonitored parameters, such as megawatt (MW), heat rate, and emissions.Other parameters may be included without departing from the scope of thepresent invention.

In addition to the real time monitoring, the system and method of thepresent invention includes alarm monitoring and tracking of user-definedsignificant events. For example, the monitoring center 10 of the presentinvention tracks and logs when a hosted unit comes on-line or goesoff-line. The monitoring center 10 tracks alarms against any generationoperational parameter that is archived in the time-series data store 18.This is implemented by querying the time-series historical data store 18for values archived for a selected operational parameter over a set timeinterval. For example, for a generator unit on-line alarm, themonitoring center 10 queries the historical archive in the data store 18for a fifteen (15) minute interval and examines breaker status recordedduring that timeframe. Any change in the monitored value represents anevent, which triggers an alarm. Once examination for the given parameterand time period is complete, the monitored time interval is marked asexamined and the alarm as tracked. Future monitoring of the historicalarchived data in the data store 18 will check subsequent intervals basedon what has already been marked as examined.

The alarming feature is not limited to tracking on/off types or digitalstate data. Rather, monitored recorded events may also be examined basedon numerical thresholds. For example, generation managers may wish tomonitor megawatt (MW) levels and create different events based on thenumber of megawatts produced at a power generation facility. The plantmay want to be alerted when the megawatt (MW) level reaches a specificlevel, such as 100, 250, and 500. Each MW level reached requires aunique action or log entry to be recorded. Such alarms are defined inthe monitoring center 10 to initiate tracking and logging. For example,in an exemplary embodiment of the present invention, alarms may bedefined by noting the following data points:

-   -   Archive historian database;    -   Archive historian data point to monitor;    -   Compare value (or alarm value);    -   Alarm log message to create when value is greater than        comparison value;    -   Alarm log message to create when value is less than comparison        value; and    -   Alarm log message to create when value is equal than comparison        value.

To ensure all intervals are examined, examined archived data may bemarked by noting:

-   -   Archive historian point examined;    -   Alarm that is tracked;    -   Examination start time; and    -   Examination end time.

This serves to baseline subsequent interval checks. It is to beunderstood that other notations may be made without departing from thescope of the present invention.

In accordance with an exemplary embodiment of the system and method ofthe present invention, monitoring of any number of hosted powergeneration units is realized by collecting qualitative (e.g., eventdata) and quantitative (e.g., cost, market data) information from aplurality of disparate data sources, converting the disparate data intoa common data format, and storing the transformed data to be served upthrough a communications network, such as the Internet, to a pluralityof client devices that may be located anywhere in the world. The variousreport interfaces in accordance with the present invention allow theuser to monitor the performance of the hosted power generation unitsincluding a comparison of the actual performance of the monitored unitwith expected (i.e., budgeted) performance. The system and method of thepresent invention generates reports using XML config files to reduce thetime to build and customize any number of reports. The XML config filesallow developers to simply map data from database stored proceduresdirectly to a report without writing any code to reduce the timerequired to deliver a report and eliminate the need for any code changesto existing applications.

It will be apparent to those skilled in the art that variousmodifications and variations can be made in the system and method of thepresent invention without departing from the spirit or scope of theinvention. Thus, it is intended that the present invention cover themodifications and variations of this invention provided they come withinthe scope of the appended claims and their equivalents.

What is claimed is:
 1. A system, comprising: a communications network; aplurality of remotely located data sources to provide power data, thepower data including quantitative and qualitative data of one or morepower generation units, wherein the quantitative data and qualitativedata comprises (1) market data, (2) operational data, (3) alarms, and(4) tracking of monitored recorded events based on numerical thresholdsincluding specific megawatt levels, and alerts when a number ofmegawatts produced at the one or more power generation units reaches thespecific megawatt levels, wherein each of the specific megawatt levelsreached requires a unique action or log entry to be recorded; and aperformance monitor in communication with the plurality of remotelylocated data sources through the communications network, the performancemonitor including a communications unit to extract the power data fromthe plurality of remotely located data sources, a data conversion unitto transform the power data into a common data format, a data store tostore the transformed power data, and a user interface unit to displaythe transformed power data on one or more client devices through thecommunications network.
 2. The system of claim 1, wherein thequantitative data includes supervisory control and data acquisition(SCADA) data and/or market data.
 3. The system of claim 1, wherein thequantitative data includes operational cost data of the one or morepower generation units.
 4. The system of claim 1, wherein thequalitative data includes event log data of the one or more powergeneration units.
 5. The system of claim 1, wherein the communicationsunit includes a gateway application programming interface (API) unit topull the power data from the plurality of remotely located data sources.6. The system of claim 5, wherein the conversion unit includes aninterface API unit to communicate with the gateway API unit and totransform the power data into the common data format.
 7. The system ofclaim 1, wherein the user interface unit includes an alarm unit to issueand track the alarms based on user-defined events.
 8. The system ofclaim 1, wherein the user interface unit includes a reporting unit todisplay the interactive reports on the one or more client devices. 9.The system of claim 8, wherein the reporting unit includes any one of adashboard reporting interface, daily operational reporting interface,unit performance interface, ad-hoc SCADA query interface, and unitstatus communications interface.